GH-471: Fix ListView reader iteration bounds - #1310

Could you extend the coverage a bit here? Two cases would pin down #471:

• the exact repro from the issue (non-nullable child, source built with startNewValue/endValue, 10 elements)
• a multi-row copy, rows copied in order, that includes a null row and an empty row

This passes because the reader is first obtained inside copyFrom, after the writes. If inVector.getReader() is called before writeIntValues(...), the copy produces [null, null]: the cached UnionListViewReader keeps its original data vector, because ListViewVector.invalidateReader() only clears reader, whereas ListVector.invalidateReader() also clears fieldReader.

This predates your changes, but it is a one-line fix and the easiest way to still get wrong data out of a flat copyFrom.

Would you mind including it here with a test? Otherwise I'm fine with a follow-up issue.

With the bound in place, read(int index, UnionHolder holder) above now stops at the end of the view, but it still ignores the result of next(). For index >= size the holder ends up on the last element of the view with isSet = 1, and for an empty view on whatever the child reader was last positioned on.

UnionListReader.read has the same loop, so this isn't new here and I won't block on it. If you want to tighten it in both readers, something like:

boolean found = true;
for (int i = -1; i < index && found; i++) {
  found = next();
}
holder.reader = data.getReader();
holder.isSet = found && data.getReader().isSet() ? 1 : 0;

Either way, a test for the out-of-range and empty-view cases would be good: testReaderIteratesListViewRangeAndResets only covers an in-range index.

Nit: #471 points out that the approach differs from UnionListReader. Mirroring its currentOffset/maxOffset pair would keep the readers aligned and drop the extra decrement:

// setPosition
maxOffset = currentOffset + size;

// next
if (currentOffset < maxOffset) {
  data.getReader().setPosition(currentOffset++);
  return true;
}
return false;

Same in UnionLargeListViewReader, where checkedCastToiInt(currentOffset++) and its import could also go, since currentOffset is already an int.

The reader has to be built by hand here because LargeListViewVector.getReader(), getReaderImpl() and copyFrom() still throw UnsupportedOperationException, so nothing in production reaches the Large half of this fix yet. That's fine for this PR, but could you say so in the description?

While you are in UnionLargeListViewReader: getMinorType() returns MinorType.LISTVIEW. It should be MinorType.LARGELISTVIEW imho.